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SYSTEMS AND METHODS FOR APPLICATION PROGRAMMING 
INTERFACES FOR SHIPPING SERVICES 

CROSS REFERENCE TO RELATED APPLICATION 

This application claims priority on U.S. Provisional Application Serial 
No. 60/227,903, filed August 25, 2000, by Stuart Willoughby and entitled 
SYSTEMS AND METHODS FOR APPLICATION PROGRAMMING 
INTERFACES FOR SHIPPING SERVICES, the entire disclosure of which Is 
incorporated herein by reference. 

DESCRIPTION OF THE INVENTION 
Field of the Invention 

This invention relates to providing an internet customer with information 
relative to shipping services using application programming interfaces ("API's" 
or "Web Tools API") supplied by the United States Postal Service ("USPS"). 
The API's are designed to allow electronic commerce ("e-commerce entities") 
to generate requests and to send them over the networic to servers for access 
to USPS shipping information. E-commerce entities may include multi- 
carriers, electronic retailers ("e-tailers"), electronic shopping malls, auction 
houses, or third party vendors that buy in broker services over a network. The 
network is preferably the Internet; however, any type of network known to 
those skilled in the art may be used. 
Background of the Invention 

Currentiy, a person desiring to send a package to a recipient may take 
the package to a mailing point where she is provided information about the 
various shipping options and costs of shipping. The person selects a shipping 
option, pays the mailer for the cost of shipping, receives a label that is applied 
to the package, and the package is then placed into a mail stream. One such 
example of a mail stream is the mail stream provided by the USPS. 
Alternatively, a person may contact a mailing company. The mailing company 
provides to the person information about the various shipping options and 
costs of shipping. The person selects a shipping option, pays the mailing 
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company for the cost of shipping, and gives the package to a mailer 
associated with the mailing company. The mailer then generates a label and 
applies it to the package. Thereafter, the mailer places the package into the 
mail stream. Either way, the person must wait to be infomied of the cost of 
mailing the package and/or wait to pay for the mailing label before the 
package may be sent. 

With the advent of e-<x)mmerce, electronic shoppers ("e-shoppers") 
may make purchases from e-commerce entities over the network. It is 
advantageous to the e-commerce entities to have e-shoppers to stay on their 
web sites and buy more items, instead of having to make separate 
arrangements for receiving information for shipping or returning a purchased 
item. It is advantageous to the e-shoppers to have the ability to receive 
shipping labels electronically for application to a packaged item or to request 
that an e-commerce entity package and ship a purchased item. 

It is accordingly an object of an embodiment of the invention to provide 
e-commerce entities witii access to USPS shipping services infonnation. The 
e-commerce entities may in tum provide such information to e-shoppers, 
thereby allowing e-shoppers to request and receive information about the 
various shipping options and the cost of mailing an Item. In addition, the e- 
shoppers may purchase mailing labels, delivery confirmation labels, or 
request merchandise return labels. The shipping options may include 
services such as Express Mall®, Priority Mail®, and Parcel Post^^, etc. The 
shipping services information may include domestic and international postal 
rates, service standards, addressing infomnation, mailing labels, merchandise 
return labels, delivery confirmation labels, etc. 

This is achieved by providing to e-commerce entities a collection of 
APi's, which provide access to servers having USPS shipping information. 
The servers may include, for example, one or more U!5PS servers. These 
API's may be coded in a language which is independent of operating system 
and hardware implementation. Preferably, the API's are implemented in 
Extensible Markup Language ("XML"); however, they are not limited to 
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language and could be written In any programming language icnown to those 
skilled in the art 

An e-commerce entity may utilize the API's to make a request to a 
USPS server over the networi< for shipping infonnation. For convenience, the 
USPS server will be referred to herein as the "Web Tools API Server." The 
Web Tools API server receives the request, generates a response to the 
request, and sends the response over the network to the e-commerce entity. 
The response may include the requested shipping information. 

SUMMARY OF THE INVENTION 

In accordance with the invention, systems and methods are disclosed 
for providing shipping services infonnation over a network by providing 
instructions to a first server from a second server which permits the first 
server to access the shipping services information residing on the second 
server over the network. The first server receives a request from a client for 
the shipping services infonnation residing on the second server. Thereafter, 
the second server provides the requested shipping services information from 
the second server to the client through the first server. 

It is to be understood that both the foregoing general description and 
the following detailed description are exemplary and explanatory only and are 
not restrictive of the invention, as claimed. 

The accompanying drawings, which are incorporated \n and constitute 
a part of this specification . illustrate embodiments of the invention and 
together with the description, serve to explain the principles of the Invention. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of a system consistent with the present 
invention. 

Figure 2 is a block diagram of an end-user/client system, e-commerce 
server system, and Web Tools API server system consistent with the present 
invention. . 

Figure 3 is a flowchart showing a method for providing shipping 
services information over a network. 
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Figure 4 is a block diagram showing data excliange occurring within a 
system for a merchandise retum API. 

Figure 4a is a diagram of a merchandise retum label including a 
delivery confirmation barcdde. 

Figure 5 is a flowchart showing a method for providing an electronic 
merchandise return label. 

Figure 6 is a block diagram showing data exchange occurring within a 
system for a rate calculation API. 

Figure 7 Is a flowchart showing a method for providing rate calculation 
information. 

Figure 8 is a block diagram showing data exchange occumng within a 
system for a tracking/confirmation API. 

Figure 9 is a flowchart showing a method for providing 
tracking/confirmation information. 

Figure 1 0 is a block diagram showing data exchange occun^ing within a 
system for a service/commitment standards API. 

Figure 11 is a flowchart showing a method for providing 
service/commitment standards infomiation. . 

Figure 12 is a block diagram showing data exchange occuning within a 
system for a delivery confirmation service AP). 

Figure 13 is a flowchart showing a method for providing a delivery 
confimiation label. 

Figure 14 is a block diagram showing data exchange occuning within a 
system for a courtesy reply label API. 

Figure 15 is a flowchart showing a method for providing a courtesy 
reply label. 

Figure 1 6 is a block diagram showing data exchange occurring within a 
system for an address information service API. 

Figure 17 is a flowchart showing a method for providing address 
information. 
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DESCRIPTION OF THE EMBODIMENTS 

Reference will now be made in detail to an exemplary embodiment of 
the invention, an example of which Is illustrated in the accompanying 
drawings. Wherever possible, the same reference numbers will be used 
throughout the drawings to refer to the same or like parts. For convenience, 
an e-shopper will be described herein as an "end-user" 

Figure 1 is a block diagram of an exemplary system with which the 
invention may be implemented. System 100 may include a plurality of end- 
user/dient systems 101 . a network 1 10, a plurality of e-commerce server 
systems 120. one or more Web Tools AP| server systems 130, and one or 
more shipping infomiation databases 150. In addition, system 100 may 
optionally iriclude one or more tracking senders 140 for tracking the delivery 
status of mailed items in a mail stream, and one or more tracking databases 
160. Network 110 may include, for example, a Local Area Network (LAN), a 
Wide Area Network (WAN), a wireless network, the Intemet, an intranet, 
and/or any other network or communication medium known to one of ordinary 
skill in the relevant art. 

Figure 2 is a block diagram of an end-user/client system 101 . e- 
commerce server system 120, and Web Tools API server system 130 
consistent with the present invention. End-user/dient system 1 01 may 
include a processor ("CPU") 225, which connects over a bus 217 to a hiemory 
200, a mass storage 220, and a network interface module 230. Memory 200 
may include an user interface module 205, a browser software module 210, 
arid an operating system 215, 

Operation of end-user/client system 101 is generally controlled and 
coordinated by operating system software 215. Operating system 215 
controls allocation of system resources and performs tasks, such as memory 
management, process scheduling, networking, and services, among other 
things. 

Mass storage 220 may include a computer-readable medium, such as 
a disk drive and a compact disc ("CD") drive or a read/write CD drive. From 
the CD drive or the read/write CD drive, software and data may be loaded 
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. onto the disk drive, which may then be copied into memory 200. Similariy. 
software and data in memory 200 may be copied onto the disk drive, which 
may then be loaded onto a read/write CD drive. 

Networtc interface module 230 may include hardware and software for 
sending and receiving data over network 110. End-user/client system 101 
may communicate with an e-commerce server system 120 over network 110 
through networt< interface module 230. 

E-commerce server system 120 may include a processor f CPU") 257, 
which connects over a bus 247 to a memory 235, a mass storage 255, and a 
networi^ interface module 260. Memoiy 235 may include one or more API 
modules 240 in the Web Tools API suite integrated with an e-commerce 
entity's application software, and operating system 245, each of which will be 
described below in detail. 

Operation of e-commerce server system 120 is generally controlled 
and coordinated by operating system software 245. Operating system 245 
controls allocation of system resources and performs tasks, such as memory 
management, process scheduling, networking, and services, among other 
things. 

Mass storage 255 may include a computer-readable medium, such as 
a disk drive and a CD drive or a read/write CD drive. From the CD drive or 
the read/write CD drive, software and data may be loaded onto the disk drive, 
which may then be copied into memory 235. Similariy, software and data in 
memory 235 may be copied onto the disk drive, which may then be loaded 
onto a read/write CD drive. 

Network interface module 260 may include hardware and software for 
sending and receiving data over network 110.. E-commerce server system 
120 may communicate with a plurality of end-user/client systems 101. and/or 
one or more Web Tools API server systems 1 30 over networi< 1 1 0 through 
networi^ interface module 260. Alternatively, e-commerce server system 120 
may communicate with one or more Web Tools API server systems 130 over 
networic 110 through a firewall 265 via network interface module 260. 
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Web Tools API server system 130 may include a processor ("CPU") 
293, which connects over a bus 275 to a memory 270, a mass storage 290, a 
network interface module 295, and one or more shipping information 
databases 150. Memory 270 may include API server module 277, standard 
API modules 285, and operating system 280, each of which will be described 
below in detail. 

Operation of Web Tools API server system 130 Is generally controlled 
and cooidinated by operating system software 280. Operating system 280 
controls allocation of system resources and perfbmfis tasks, such as memory 
management, process scheduling, networking, and services, among other 
things. 

Mass storage 290 may include a computer-readable medium, such as 
a disk drive and a CD drive or a read/write CD drive. From the CD drive or 
the read/write CD drive, software and data may be loaded onto the disk drive, 
which may then be copied into memory 270. Similarly, software and data in 
memory 270 may be copied onto the disk drive, which may then be loaded 
onto a read/write CD drive. 

Networi< interface module 295 may include hardware and software for 
sending and receiving data over networi< 110. Web Tools API server system 
130 may communicate with a plurality of e-commerce server systems 120 
over network 110 through networi< interface module 295. Alternatively, Web 
Tools API server system 1 30 may communicate with a plurality of e- 
commerce server systems 120 over network 110 through a firewall 265 via 
networi< interface module 295. In addition, the Web Tools API server system 
130 may send and/or receive shipping infonnation to/from one or more 
shipping Infonnation databases 150. Optionally, the Web Tools API server 
system 130 may communicate with one or more tracking servers 140 over 
networi< 110 through networi< interface module 295 to request and receive 
information from one or more tracking databases 160. 

In one example, an e-commerce entity may make a request to an API 
provider for one or more API modules in the Web Tools API suite. The API 
provider may include, for example, the USPS. The e-commerce entity 
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registers with the API provider and receives a usemame and password for 
connecting to a Web Tools API Sender 1 30. The API provider may send the 
requested API modules to the e-commerce entity by any known delivery 
method. For example, the API provider may send the requested API modules 
by an email, or by placing the API modules on a CD or floppy disk and mailing 
them to the e-commerce entity. In another example, the API provider may 
access an API server module 277 on a Web Tools API server 130 to send the 
requested API modules over a network 1 10 to an e-commerce server 120 
specified by the e-commerce entity. Thereafter, the e-commerce entity may 
integrate the API modules with Its application software on one or more e- 
commerce servers 1 20 to generate Extensible Markup Language ("XML") 
requests to the Web Tools API server 130 for shipping information. The API 
modules may provide for processing multiple requests within a single 
transaction. 

Once the API modules are integrated with application software of an e- 
commerce server 120, an end-user 101 may access the e-commerce server 
120 over a network 110 through a client system 101 and make a request for 
information, for example, a request for a merchandise return label. E- 
commerce server 120 generates an XML request based on the request from 
the end-user. Thereafter, e-commerce server 120 sends the request to the 
Web Tools API sender 130. Web Tools API server 130 receiyes the request 
and calls an appropriate standard API module 285 to processes the request. 
Once the request is processed, Web Tools API server 130 sends an XML 
response back to e-commerce server 120. E-commerce server 120 may send 
the XML response back to the end-user at client system 101 through network 
110. If e-commerce server 120 detects an error condition in the XML 
response, it may notify the end-user of the error condition. Othenwise, e- 
commerce server 120 retrieves the requested information from the XML 
response and sends it to the end-user, in this example, the merchandise 
return label is sent to the end-user. 

Figure 3 is a flowchart showing a method for providing shipping 
services information over a network. The discussion that follows is a more 
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detailed description of the processing perfonned by e-commerce server 120 
and Web Tools API server 130. An e-commerce server 120 receives a 
request from an end-user through a client system 101 (stage 300). E- 
commerce server 120 generates an XML request based on the request from 
the end-user (stage 310). The XML request may include a tag that specifies a 
piarticular API in the standard API modules 285 to use In processing the 
request, and one or more tags that represent information relevant for 
processing the request The fomriat of an XML request for each API is 
described below in detail. In addition, the USPS may provide to an e- 
commerce entity example integration source code that may be used by an e- 
commerce server 120 to generate XML requests. 

Next, e-commerce server 120 may make a network connection to a 
Web Tools API server 130 (stage 320). The USPS may provide to an e- 
commerce entity example integration source code that may be used by an e- 
commerce server 1 20 to connect to a Web Tools API server 1 30. 

Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API server 130 through networi< 110 (stage 330). The Web Tools API 
server 130 receives the XML request and determines, based on the XML 
request, which API within the standard API modules 285 to call to process the 
request Next, API server module 277 calls the applicable API in the standard 
API modules 285 to process the request, and sends an XML response to the 
e-commerce server 1 20 through networic 110. E-commerce server 1 20 
receives the XML response from the Web Tools API server 1 30 through 
network 1 10 (stage 340). The XML response may include one or more tags 
that specify a type for the response, and one or more tags that include the 
requested infomiation. The format of an XML response for each API is 
described below in detail. 

E-commerce server 120 determines, based on the XML response, 
whether an enror occunred during the processing of the XML request by the 
Web Tools API server 1 30 (stage 350). If an error occun-ed ("Yes"), e- 
commerce server 120 generates an en-or status, based on the XML response, 
and sends it to client system 101 through network 110 (stage 370). Client 
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system 101 may display the error status to the end-user through browser 
software module 210. Otherwise ("No"), e-commerce server 120 may 
generate a reply response, based on the XML response, and send it to client 
system 101 through network 110 (stage 360). Client system 101 may display 
the reply response to the end-user through browser software module 210 or 
user Interface module 205. Alternatively, e-commerce server 120 sends the 
XML response received from Web Tools API server 130 to client system 101 
through network 110. 

Figures 4-17 describe API's that may be included in the Web Tools API 
suite. However, the API's are not limited to the API's described herein. 

Figure 4 is a block diagram showing data exchange occurring within a 
system for a merchandise retum API. Specifically, Figure 4 shows an 
example of the flow of information for a merchandise retum API, which is a 
merchandise retum solution set up for e-commerce entity's that have 
customers who need to retum a package that they've purchased. The 
merchandise retum API has been specifically designed for e-commerce 
entities that elect to provide to their customers a pre-paid postage retum label. 
This API facilitates returns by allowing e-commerce entities to request and 
receive a merchandise return label for merchandise retum, which the e- 
commerce entity can provide to its customers or end-users through any 
known distribution medium, such as email, regular mail, fax^ etc. 

As shown in Figure 4, an end-user accesses an e-commerce server 
1 20 over a network 110 flirough a client system 1 01 and makes a request to 
retum a purchased item to a retailer. E-commerce server 120 may provide to 
flie end-user, based on infomiation supplied by the end-user, a list of items 
that were purchased. The end-user may select from the list one or more 
items to return. For purposes of this example, the end-user selects a single 
item. Thereafter, e-commerce server 120 may detemiine whether the end- 
user has permission to retum the selected item, and if so, whether the item 
requires insurance for shipping. If tiie end-user has permission to retum the 
selected item to the retailer, e-commerce sender 120 generates an XML 
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request based on the information supplied by the end-user and the selected 
Item. 

The request includes, for example, the name and address of the 
customer who purchased the item, name and address of the retailer who sold 
the Item, service type, pemnit information, Postage Due Unit ("PDU") 
information, label image type, insurance value, package weight, retum 
materials authorization ("RMA"), and mailing acknowledgement. The mailing 
acknowledgement is an optional service that provides a customer with an 
acknowledgement when an item is returned/delivered to a retailer. The e- 
commerce entity may be required to register with the USPS to receive a user 
ID and password to allow e-commerce sender 120 to pre)vide a valid user ID 
and password |n each XML request. 



For example, the XML request Includes the following tags: 



Input 


XML Tag 


Values Allowed 


Request 


<EMRSV2.0Request. , . 


Input tag exactly as 
presented. 


User ID 


...USERIDs^userid"... 


Use user ID provided with 
registration. 


Password 


. . .PASSWORD=''password''> 


Use password provided with 
registration. 


Customer's 
Name 


<CustomerName> 


Maximum characters 
allowed: 32 


Customer's 
Address 


<CustomerAddress> 


Maximum characters 
allowed: 24 . 


Customer's 
City 


<CustomerCity> 


Maximum characters 
allowed: 21 


Customer's 
State 


<CustomerState> 


Maximum characters 
allowed: 2 


Customer's 
ZIP Code® 


<CustomerZip5> 


Input tag exactly as 
presented, not all caps. 
Maximum characters 
allowed: 5 


Retailer's 
Name 


<RetailerName> 


Maximum characters 
allowed: 32 


Retailer's 
Address 


<RetailerAddress> 


Maximum characters 
allowed: 32 


Post Office 

Permit 

Number 


<PermitNumber> 


Input permit number provided 
by your local post office. 


City Issuing 


<PermitlssuingPOCity> 


1 Maximum characters 
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Post Office 
Permit 




allowed: 15 


State Issuing 
Post Office .. 
Pemnit 


<PenmitlssuingPOState> 


Maximum characters 
aiiowea. £. 


ZIP Code® of 
Post Office 
Issuing Permit 


<PermitlssuingP0Zlp5> 


tnpul lag exacuy as 
presented, not all caps. 
Maximum characters • 
allowed: 5 


Postage Due 
Unit PO Box 


<PDUPOBo)0 


Maximum cnaraciers 
allowed: 24 


Postage Due 
Unit City 


<PDUCity> 


Maximum characters 
allowed: 15 


Postage Due 
Unit State 


<PDUState> 


Maxinrium characters 
allowed: 2 


Postage Due 
Unit ZIP 
Code® 


<PDUZip5> 


Input tag exactly as 
presented, not all caps. 
Maximum characters 
allowed: 5 


Postage Due 
Unit ZIP 
Code® + 4 


<PDUZip4> 


Input tag exactly as 
presented, not all caps. 
Maximum characters 
allowed: 4 


Service Type 
Requested 


<SeiviceType> 


Valid entries are: "First 
Class." "Priority," "Parcel 
Post," "Bound Printed 
Matter," "Special Standard," 
or Library Rate. 


Delivery 

Confinnation™ 

Service 


<DeliveryConfirmation> 


The valid values are True" or 
"False" 


Insurance 
Desired by 
Pemiit Holder 


<lnsuranceValue> 


Enter numeric cunrency with 
dollars and cents (no dollar 
sign). If insurance is not 
required, leave value blank. 
A value of "0.00" will result in 
an error beinq retumed. 


Unique Parcel 

Identification 

Number 


<MailingACivr aCI\ciy cl l-'^ 


E-commerce entity 

assignable number. 

Maximum characters 

allowed: 24. Value entry is 

optional. 

Refer to "Mailing 

Acknowledgement" below. 


Package 
Weight in 
Pounds 


<WeightlnPounds> 


Value must be numeric. 
Maximum characters 
allowed: 2. 
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Package 
Weight in 
Ounces 


<WeightinOunces> 


Value must be numeric. 
Maximum characters 
allowed: 4. 


Return 

Materials 

Authorization 


<RMA> 


Value entry is optional. 


i_abel Image 
Type 


<lmageType> 


Either of two values allowed: 
T"IF"orTDF- 



Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API server 130 through networic 1 10 (stage 330). Web Tools API 
server 130 receives the XML request, and may call a merchandise retum API 
module 285 to generate a merchandise retum label based on the XML 
request. The merchandise retum label may, for example, be in Portable 
Document Format ("PDF") or Tagged Image File ("TIF") fomiat, which is 
determined by the value supplied In the Label Image Type tag in the XML 
request. Next, merchandise retum API module 285 generates an XML 
response, which includes the merchandise retum label. The merchandise 
return label may include forwarding information such as, address of the 
sender, address of a recipient, barcode, RMA, and an indication of pre-paid 
postage. 



For example, the XML response includes the following tags: 



Output 


XML Tag 


Type of Response 


<EMRSV2.0Response> 


Zone 


<Zone> 


Image of Merchandise Retum Label 


<MerchandiseRetumLabel> 


Insurance Cost 


<lnsuranceCost> 



However, if Web Tools API server 1 30 detects an en^or condition in 

processing a request from an e-commerce entity, the XML response includes 

information about the error. Thus, if Web Tools API server 1 30 detects an 

en"or condition, it may generate an XML response with tags that may have the 

following format: 

<Error> 

<Number></Number> 
<Source></Source> 
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<Description></Descriptlon> 
<HelpRIe></HelpFile> 
<HelpContext></HelpContext> 
</ErTor> 

The number tag includes an emor number generated by Web Tools API 
server 1 30. The source tag includes information about the source code 
component and API that generated the error condition on Web Tools API 
server 1 30. The description tag includes a description of the error. 

After merchanjdise return API module 285 generates the XML 
response, Web Tools API server 130 sends the XML response to the e- 
commerce server 120 through networic 110. E-commeroe server 120 receives 
the XML response and extracts the merchandise retum label. E-commerce 
server 120 may send the merchandise return label to client system 101 
through networi< 110. Client system 101 may display the merchandise retum 
label to the end-user. The end-user may then print the rnerchandise retum 
label and attach it to the packaged item. Alteniatively, e-commerce server 
120 may fax the merchandise retum label to the end-user, email the 
merchandise retum label to the end-user, or mail ft to the end-user. 

Figure 4a is a diagram of a merchandise retum label 410 generated by 
Web Tools API server 1 30. As shown in figure 4a, the merchandise return 
label 410 includes a retum label 420 having fonvarding Information such as, 
address of a sender 425, address of a recipierit 445, delivery cbnfimriation 
barcode 430, RMA 440, and an indication of pre-paid postage 435. The 
postage for the retum label is pre-paid by the e-commerce entity or the 
retailer, so the end-user fs not required to apply postage to the retum label. 
Optionally, the merchandise retum label may include a mailing 
acknowledgment form 450 coupled to the return label 420 and a mailing 
acknowledgement identification number 415 is included on the mailing 
acknowledgment form 450 and the return label 420. 

Figure 5 Is a flowchart showing a method for providing an electronic 
merchandise return label. As shown in Figure 5, an end-user accesses an e- 
commerce server 120 through a client system 101 , and makes a request to 
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return merchandise to a retailer (stage 500). E-commerce server 120 may 
display to the end-user, based on infomiation supplied by the end-user, a list 
of items of merchandise that were purchased from the retailer (stage 505). 
The end-user selects from the list an item of merx^handise to return (stage 
510). Thereafter, e-commerce server 120 determines whether the end-user 
has permission to return the selectied merchandise by requesting approval 
from the retailer (stage 515). If the end-user does not have permission to 
return the merchandise to the retailer ("No"), e-commerce server .120 sends a 
message to the end-user informing her that her request is denied and the 
transaction stops (stage 520). Otherwise ("Yes"), the end-user has 
permission to retum the merchandise to the retailer. E-commerce server 120 
generates an XML request based on the information supplied by the end-user 
and the selected merchandise (stage 525). 

Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API server 130 through network 110 (stage 530). Web Tools API 
server 130 receives the XML request (stage 535). Next. Web Tools API 
server 130 may call a merchandise return API module 285 to generate an 
XML response, which includes the merchandise return label (stage 540). 
Web Tools API server 130 sends the XML response to e-commerce server 
120 through network 110 (stage 545). E-commefce server receives the XML 
response and extracts the merchandise return label (stage 550). E- 
commerce server 120 sends the merchandise retum label to the end-user at 
client system 101 through network 110 (stage 555). Client system 101 
displays the merchandise retum label to the end-user. The end-user may 
then print the merchandise retum label and attach it to the packaged item. 
Altematively, e-commerce server 120 may fax the merchandise retum label to 
the end-user, email the merchandise retum label to the end-user, or mail it to 
the end-user. 

In an alternate example, the e-commerce entity may request and 
receive a courtesy reply label instead of a merchandise retum label. 
However, unlike the merchandise retum labels, postage is not pre-paid. The 
courtesy reply label will be described below in detail. 
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Figure 6 is a blocl< diagram shovying data exchange occurring within a 
system for a rate calculation API. The rate calculation API's provide access to 
domestic and/or international rates for various shipping rates such as Express 
Mail®. Priority Mail®, and Parcel Post™, to assist In making shipping 
decisions. 

As shown in Figure 6, an end-user accesses an e-commerce server 
1 20 over a network 110 through a dient system 101 and makes a request for 
rate infonmation for shipping a package. In addition, the end-user supplies 
informatton about the package to be shipped, the point of destination, and In 
the case of domestic mailing, the point of origin. E-commerce server 1 20 
generates an XML request for the rate infonnation based on , the information 
supplied by the end-user. 

For example, the XML request for domestic rates includes the following 



tags: 



Input 


XML Taq 


Values Allowed 


Type of 
Request 


<RateRequest... 


Input tag exactly as presented. 


User ID 


...USERID='*userid".., 


Use user ID provided with 
registration. 


Password 


. . PASSWORD="password • > 


Use password provided with 
registration. 


Package 
ID Number 


<Package ID="#'> 


No restrictions on number or 
type of characters. 


Type of 
Service 
Requested 


<Service> 


The service type must be one of 
the following: "Express," 
Triority." or "Parcel" The API 
validates the entry to the service 
type. 


Origination 
ZIP Code® 


<ZipOrigination> 


Input tag exactly as presented. 
ZIP Codes® must be valid. 
Maximum characters allowed: 5 


Destination 
ZIP Code® 


<ZipDestination> 


Input tag exactly as presented. 
Zl P Codes® must be valid . 
Maximum characters allowed: 5 


Package 
Weight in 
Pounds 


<Pounds> 


Value must be numeric. 
Package weight cannot exceed 
70 pounds. Parcel Post™ 
packages must weigh at least 1 
j)ound. 


Package 


<Ounces> 


Value must be numeric. 
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Weight in 
Ounces 




Package weight cannot exceed 
70 pounds. Parcel PostT** 
packages must weigh at least 1 
pound. 


Shipping 
Container 


<Container> 


See below for valid entries. 


Package 
Size 


<Slze> 


Valid entries are: "Regular," 
"Large." and "Oversize." 


Machinable 


<Machinable> 


The Machinable tag is required 
for Parcel Post™ only. The 
value entered must be either 
Tme" or "False" 


For example, the XML request for International rates includes the 
following tags: 


Input 


XML Tag 


Values Allowed 


Type of 
Request 


<lntlRateRequest.. 


Input tag exactly as presented. 


User ID 


...USERID="userid"... 


Use user ID provided with 
registration. 


Password 


. . .PASSWORD="password"> 


Use password provided with 
registration. 


Package 
ID Number 


<PackagelD="#"> 


No restriction on number or type 
of characters. 


Weight of 

package 

(pounds) 


<Pounds> 


Value must be numeric. Package 
weight cannot exceed 70 
pounds. Parcel Post™ packages 
must weigh at least 1 pound. 


Weight of 

package 

(ounces) 


<Ounces> 


Value must be numeric. Package 
weight cannot exceed 70 
pounds. Parcel Post™ packages 
must weigh at least 1 pound. 


Type of 
Mail 


<MailType> 


The following are valid 
international mail types: 
"letters or letter packages" 
"other packages" 
"postcards or aerogrammes" 
"regular printed matter" 
"books or sheet music" 
"publishers' periodicals" 
"matter for the blind" 


Destination 
Country 


<Country> 


Entries must be from the USPS 
list of valid countries. 



Thereafter, e-commerce server 120 sends the XML request to a Web 



Tools API server 130 through network 110. Web Tools API server 130 
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receives the XML request and calls a rate calculation API module 285 to 
process the request Rate calculation. API module 285 queries a shipping 
information database 150 for the requested rate infomnation based on the 
XML request. Next, rate calculation API module 285 generates an XML 
response based on results of information returned from the query. For 
example, if tiie request is for domestic rate infomnation, tfie XML response 



includes the following tags: 



Output 


XML Tag 


Comments 


Type of Response 


<RateResponse> 




Package Identification 
Number 


<Package 
ID="#'^ 




Type of Service 
Required 


<Sennce> 




Origination ZIP Code® 


<ZipOrigination> 




Destination ZIP Code® 


<ZipDestination> 




Package Weight 
(Pounds) 


<Pounds> 




Package Weight 
(Ounces) 


<Ounces> 




Shipping Container 


<Container> 




Package Size 


<Si2e> 




Postage Rate Charged 


<Postage> 




Postal Zone 


<Zone> 


U.S. Postal Service Zones are 
used for Priority Mail® 
packages over 5 lbs. 



For example, if the request is for international rate infomiation, the XML 



response includes tiie following tags: 



Output 


XML Tag 


Comments 


Type of Response 


<lntiRateResponse> 




Package Identification Number 


<Packaqe ID="#"> 




Services Identification Number 


<Service ID="r> 


For each package 
submitted, the 
available services 
for that package 
are returned with a 
separate 
identification 
number. 


Weight of package (pounds) 


<Pounds> 




Weight of package (ounces) 


<Ounces> 




Type of Mail 


<MailType> 




Destination Country 


<Country> 
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Postage Rate Charged 


<Postage> 




.qp^p/jnP^ nommitments 


<5;\/rnommitments> 




Service Description 


<SvcDescription> 




Maximum Dimensions of 
Package Allowed 


<MaxDimensions> 




Maximum Weight of Package 
Allowed 


<Ma)d/Veight> 





Web Tcx>ls API server 130 sends the XML response to e-commerce server 
120 through netwoilc 110. E-commerce server 120 receiveis the XML 
response and extracts the rate infonnation. E-commerce server 120 sends 
the rate information to the end-user at client system 101 through network 1 10. 
Client system 101 may display the rate information to the end-user. 

Figure 7 Is a flowchart showing a method for providing rate calculation 
Information. As shown In Figure 7, an end-user accesses an e-commerce 
server 120 through a client system 101 (stage 700). The end-user makes a 
request to e-commerce server 120 for rate infomnation for shipping a package, 
and supplies information about the package to be shipped, the point of 
destination, and In the case of domestic mailing, the point of origin (stage 
710). E-commerce server 120 generates an XML request for the rate 
infonnation based on the Infoniiation supplied by the end-user (stage 720). 
Thereafter, e-commerce server 120 sends the XML request to a Web Tools 
API server 130 through network 1 10 (stage 730). 

Web Tools API server 130 receives the XML request (stage 740). 
Thereafter, Web Tools API server 130 calls a rate calculation API module 285 
to process the request (stage 750). Rate calculation API module 285 queries 
a shipping Information database 150 for the requested rate information based 
on the XML request. Next, rate calculation API module 285 generates an 
XML response based on results of infonnation returned from the query. The 
XML response includes the requested rate infonnation. Web Tools API server 
130 sends the XML response to e-commerce sen/er 120 through network 110 
(stage 760). E-commerce server 1 20 receives the XML response and 
extracts the rate information. E-commerce server 120 sends the rate 
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information to the end-user at client system 101 through network 110 (stage 
760). Client system 101 may display the rate infomiation to the end-user. 

Figure 8 Is a block diagram showing data exchange occurring vwthin a 
system for a tracking/confimiation API. The tracklng/confimnation API 
provides for determining the delivery status of Priority Mail® and Parcel 
Post™ mail items and for Delivery Confimiation™ of mail items. It also 
provides for tracking Express Mail® shipments. 

As shown in Figure 8, an end-user accesses an e-commerce server 
120 over a networic 110 through a client system 101 and makes a request for 
tracking infomiation for a piackage, and supplies Information about the 
package such as a unique identification code or tracking ID. A ^tracking ID" 
may also be referred to herein as a ''package identification code." E- 
commerce server 120 generates an XML request for the tracking/confirmation 
information based on the infomiation supplied by the end-user. 

For example, the XML request for tracking/confimiation information 
includes the following tags: 



Input 


XML Tag 


Values Allowed 


Type of Request 


<TrackRequest.-. 


Input tag exacUy as 
presented. 


User ID 


,..USERID="userid".,. 


Use user ID provided with 
registration. 


Password 


., .PASSWORD="password"> 


Use password provided 
with registration. 


Package Tracking 
ID Number 


<TracklD ID="#########"> 


No restrictions on number 
or type of characters. 



Tools API server 130 through network 1 10. Web Tools API server 130 
recelveis the XML request and calls a tracking/confimiation API module 285 to 
process the request. Tracking/confirmation API module 285 sends the XML 
request to a tracking server 140 through network 110, thereby fpnwanding the 
tracking data to tracking server 140. Tracking server 140 queries one or more 
tracking databases 160 for the requested tracking infomiation based on the 
XML request. Next, tracking server 140 retrieves the tracking infomiation 
from tracking database 160 and sends it tracking/confirmation API module 



wo 02/17045 . . PCTAIS01«6(556 

21 

285 through network 110. Tracking/confirmatidn API module 285 generates 
an XML response based on the tracking infonnation received from tracking 
server 140. 

For example, the XML response includes the following tags: 



Output 


XML Tag 


Type of Response 


<TrackResponse> 


Package Tracking ID Number 


<Tracklnfo ID="#######^ 


Tracking Summary Infomiation 


<TrackSummary> 


Tracking Detail Information 


<TrackDetail> 



After tracking infonnation API module 285 generates the XML 
response, Web Tools API server 130 sends the XML response to e- 
commerce server 120 through network 110. E-commerce server 120 receives 
the XML response and extracts the tracking information. E-commerce server 
120 sends the tracking infonnation to the end-user at client system 101 
through network 1 10. Client system 101 may display the tracking information 
to the end-user. 

Figure 9 is a flowchart showing a method for providing 
tracking/confirmafion infomiation. As shown in Figure 9, an end-user 
accesses an e-commerce server 120 over rietwork 110 through a client 
system 101 (stage 900). The end-user makes. a request to an e-commerce 
server 120 for tracking/confirmation information for a package, and supplies 
information about the package such as a unique identification code or tracking 
ID. (stage 910). E-commerce server 120 generates an XML request for the 
tracking/confirmation infomiation based on the information supplied by the 
end-user (stage 920). Thereafter, e-commerce server 120 sends the XML 
request to the Web Tools API server 130 through network 1 10 (stage 930). 

Web Tools API server 130 receives the XML request and calls a 
tracking/confimnation API module 285 (stage 940). Tracking/confirmation API 
module 285 sends the XML request to a tracking sender 140 (stage 950). 
Tracking server 140 searches one or more tracking databases 1 60, and 
retrieves the requested tracking/confimnation infonnation. Thereafter, tracking 
server 1 40 sends the tracking/confimnation information to 
tracking/confirmation API module 285 through network 110 (stage 960). Next. 
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tracking/confirmation API module 285 generates an XML response based on 
the tracking/confinnation infomiation received from tracking server 140 (stage 
970). Web Tools API sender 1 30 sends the XML response to e-commerce 
server 1 20 through network 110 (stage 980). 

E-commerce server 1 20 receives the XML response and extracts the 
tracking/confinnatfon infomiation. E-commerce server 120 sends the 
tracking/confinnation infomiation to the end-user at client system 101 through 
network 1 10 (stage 990). Client system 101 may display tiie 
tracking/confimiation infomiation to the end-user. Alternatively. Web Tools 
API server 130 sends tiie tracking/confinnation infomiation instead of the XML 
response to e-commerce server 120 tiirough network 110 (stage 980). 
Thereafter, e-commerce server 120 sends ttie tracking/confirmation 
Infomnation to the end-user at client system 101 through network 110 (stage 
990). 

Figure 10 is a block diagram showing data exchange occurring within a 
system for a service/commitment standards API. The sen/ice/commitment 
standards API's may be used to detemnine the number of days (on average) it 
takes for a mail item to arrive at its destination. One such API is for Priority 
Mail® service standards, which returns the number of days it will take a 
Priority Mail® item to arrive at its destination. Another API is for standard mail 
service standards, which rebjms tiie number of days it will take a standard 
mail item to arrive at its destination. Yet anotiier API is for Express Mall® 
service standarels, which retums tiie sennce commitments for Monday-Friday, 
Saturday-Sunday, and Holiday delivery. 

As shown in Figure 10, an end-user accesses an e-commerce server 
120 over a network 1 10 tiirough a client system 1 01 and makes a request for 
service/commitment infomiation for shipping a package from point A to point 
B, and supplies Infomiation about the package to be shipped. The 
infomiation supplied by the end-user may include the point of origin (A), 
destination (B), and type of mail service, for example. Priority Mail. E- 
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commerce server 120 generates an XML request for the service/commitment 
information based on .the infoonation supplied by the end-user. 

For example, the XML request for Priority Mail® service standards 
includes the following tags: 



Input 


XMLTafl 


Values Allowed 


Type of 
Request 


<PriorftyMailRequest. . . 


Input tag exactly as presented. 


Usemame 


...USERID= usend ... 


use user lu pruviueu wiui • 
reqistration. 


Password 


. . .PASSWORD="password"> 


Use password provided with 
reqistration. 


Origination 
ZIP Code® 


<OriglnZip> 


Origination and destination ZIP 
Codes® must be valid. Only 
the first 3 digits of the Zip 
Code® are entered between 
the open tag and close tag. If a 
1 - or 2-digit ZIP Code® is 
entered, it will be treated the 
same as a SKligit zip prefixed 
with 2 or 1 zeros, respeciiveiy. 
If a 4- or 5-digit ZIP Code® is 
entered, the last 1 or 2 digits 
will be ignored. 


Destination 
ZIP Code® 


<DestinationZip> 


Origination and destination ZIP 
Codes® must be valid. Only 
the first 3 digits of tiie Zip 
Code® are entered between 
. the open tag and close tag. If a 
1- or 2-digit ZIP Code® is 
entered, it will be treated the 
same as a 3-digit zip prefixed 
with 2 or 1 zeros, respectively. 
If a 4- or 5-dig'it ZIP Code® is 
entered, the last 1 or 2 digits 
will be ignored. 


For example, the XML request for Parqel Post™ service standards, 
which is a component of standard mail services, includes the following tags: 


Input 


XMLTaq 


Values Allowed 


Type of 
Request 


<StandardBRequest. . . 


Input tag exactly as presented. 


Usemame 


...USERID="userid"... 


Use user ID provided with 

reqistration. 


Password 


PASSWORD="Dassword"> 


Use password provided with 
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I registration. 

Origination <OriginZip> Origination and destination ZIP 

ZIP Code® Codes® must be valid. Only 

the first 3 digits of the Zip 
Code® are entered between 
the open tag and close tag. if a 
1-or2-digitZIPCode®ls 
entered, It will be treated the 
same as a 3-digit zip prefixed 
with 2 or 1 zeros, respectively. 
If a 4- or 5-digit ZIP Code® is 
entered, the last 1 or 2 digits 

will be ignored. 

Destination <DestinationZip> Origination and destination ZIP 

ZIP Code® Codes® must be valid. Only 

the first 3 digits of ttie Zip 
Code® are entered between 
the open tag and dose tag. If a 
1- or 2<ligit ZIP Code® is 
entered, it will be treated tiie 
same as a 3-diglt zip prefixed 
with 2 or 1 zeros, respectively. 
If a 4- or 5-digit ZIP Code® is 
entered, the last 1 or 2 digits 

I will be ignored. 

For example, the XML request for Express Mail® service standards 



includes the following tags: 



Input 


XML Taq 


Values Allowed 


Type of 
Request 


<ExpressMail Request. . . 


Input tag exactly as presented. 


User ID 


...USERID="userid"... 


Use user ID provided with 
registration. 


Password 


. ..PASSWORD="password"> 


Use password provided with 
registration. 


Origination 
ZIP Code® 


<OriginZip> 


Origination and destination ZIP 
Codes® must be valid. If a 1- 
to 4-dlgit ZIP Code® is 
entered, it will be treated as if 
prefixed with 4 to 1 zeros, 
respectively. 


Destination 
ZIP Code® 


<DestinationZip> 


Origination and destination ZIP 
Codes® must be valid. If a 1- 
to4-digitZIP Code® is 
entered, it will be treated as if 
prefixed with 4 to 1 zeros, 
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I I respectively. 

Thereafter; e-commerce server 120 sends the XML request to a Web 

Tools API server 130 through network 110. Web Tools API server 130 

receives the XML request and calls a service/commitment API module 285 to 

process the request. Sendee/commitment API module 285 searches a 

shipping infonmation database 150 for the requested service/commrtment 

infonnation based on the XML request. Next, service/commitment API 

module 285 generates an XML response based on retrieved 

service/commitment information. 

For example, the XML response for Priority Mail® service standards 



includes the following tags:. 



Output 


XML Tag 


Comments 


Response Type 


<PriorityMailResponse> 




Origination ZIP Code® 


<OriginZip> 


Only the first 3 digits of the 
ZIP Code® are returned. 


Destination ZIP 
Ctode® 


<DestinationZip> 


Only the first 3 digits of the 
ZIP Code® are returned. 


Average number of 
days it will take the 
package to arrive 


<Days> 





For example, the XML response for Parcel Post™ service standards 



Includes the following tags: 



Output 


XML Tag 


Comments 


Response Type 


<StandardBResponse> 




Origination ZIP 
Code® 


<OriginZlp> 


Only the first 3 digits of the 
ZIP Code® are retumed. 


Destination ZIP 
Code® 


<DestinationZip> 


Only the first 3 digits of the 
ZIP Code® are returned. 


Average number of 
days it will take the 
package to arrive 


<Days> 





For example, the XML response for Express Mail® service standards 



includes the following tags: 



Output 


XML Tag 


Comments 


Response Type 


<ExpressMailResponse> 




Origination ZIP Code® 


<OriqinZip> 




Destination ZIP Code® 


<DestinationZip> 




Monday-Friday Service 
Commitment (12:00 pm. 


<MonFriCommitment> 
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3:00 pm. 2-day commitment) 






Saturday-Sunday Service 
Commitment (12:00 pm, 
3:00 pm, 2-day commitment, 
where applicable) 


<SatSunCommitnient> 


Holiday service is 
the same as 
Sunday Service 
Commitment. 



response, Web Tools API seiver 1 30 sends ttie XML response to e- 
commerce server 120 through network 110. E-commerce server 120 receives 
the XML response and extracts the servlce/oommitment infomiatlon. E- 
commerce server 120 sends the service/commitment infonnation to the end- 
user at client system 1 0 1 through network 110. Client system 1 01 may 
display the service/commitment infomnation to the end-user. Alternatively, 
Web Tools API server 130 sends the service/commitment information instead 
of the XML response to e-commerce server 120 through network 110. 
Thereafter, e-commerce server 1 20 sends the service/commitment 
information to the end-user at client system 1 01 through network 110. 

Figure 1 1 is a flowchart showing a method for providing 
sen^ice/commitment standards infonnation. As shown in Figure 11. an end- 
user accesses an e-commerce seiver 120 through a client system 101 (stage 
1 100). The end-user makes a request to e-commerce server 120 for 
service/commitment Infonnation for shipping a package from point A to point 
B. and supplies Information about the package to be shipped (stage 1 1 1 0). 
The infonnation supplied by the end-user may Include the point of origin (A), 
destinatton (B), and type of mail sendee, for example, Priority Mail. E- 
commerce server 120 generates an XML request for the service/commitment 
infonnation based on the information supplied by the end-user (stage 1 120). 
Thereafter, e-commerce server 120 sends the XML request to Web Tools API 
sender 130 through network 1 10 (stage 1 130): 

Web Tools API server 130 receives the XML request and calls a 
sen/ice/commitment API module 285 to process the request (stage 1 1 40). 
Sen/ice/commitment API module 285 searches a shipping infonnation 
database 150 for the requested service/commitment infonnation based on the 
XML request and retrieves the requested service/commitment information. 
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Next, service/commitment API module 285 generates an XML response 
based on retrieved service/commitment Information (stage 1150). Web Tools 
API server 130 sends the XML response to eK»mmerce server 120 through 
network 1 10 (stage 1160). E-commerce server receives the XML response 
and extracts the service/commitment infonnation. E-commerce server 120 
sends the service/commitment infonnation to the end-user at dient system 
101 through network 110 (stage 1 170). Client system 101 may display the 
service/commitnient Infomration to the end-user. Alternatively, Web Tools 
API server 130 sends the service/commitment Infomiation instead of the XML 
response to e-commerce server 1 20 through networic 1 1 0 (stage 1 1 60). 
Thereafter, e-commerce server 120 sends the service/commitment 
Infonnation to the end-user at client system 101 through network 110 (stage 
1170). 

Figure 12 is a block diagram showing data exchange occuning within a 
system for a delivery confirmatfon service API. A delivery conflnnation 
service API provides Iriformation about the delivery status of Priority Mail® 
and Standard B packages, including the date, time, and ZIP Code® of 
delivery, as well as attempted deliveries, fonwarding, and returns. This API 
/nay also provide a Delivery Confinnation™ label for Priority Mall® and 
Standard B, which Includes Parcel Post™, Bound Printed Matter. Special 
Standard, and Library Rate. The label returned by the API may be printed by 
the sender of a mail item such as a package, and attached to the package. 
Standard B may be refen-ed to as "Package Services." Special Standard may 
be refen-ed to as "Media Mall." Library Rate may be refenred to as "Library 
Mail." 

This API provides for an end-user to request and receive a delivery 
confirmation barcode label for placement on either a Priority Mail® or a 
Standard B-mail item. An end-user may obtain, at no charge, a delivery 
confinnation barcode label and a package Identification code ("PIC"). The 
PIC is a unique identifier associated with a delivery confinnation barcode. 
The delivery confinnation barcode allows a sender and a recipient of a Priority 
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Mail® or a Standard B-mail item, sucli as a package to obtain delivery 
confirmation information about the paclcage's delivery based on the PIC. As 
the package travels through a miail stream such as that provided by the 
USPS, the delivery confinnation barcode is scanned and the scanned 
information is stored in one or more tracking databases. Upon delivery of the 
package, the delivery confimiation barcode is scanned again, and the 
scanned informatfon is stored in one of the tracking databases. 

As shown in Figure 12, an end-user accesses an e-commerce server 
120 over a network 110 through a client system 101 and makes a request for 
a delivery confimiation barcode label, and supplies infpmiation about the i 
package on which the delivery confirmation barcode label will be placed. The 
information supplied by the end-user may include information about the 
sender, receiver, package weight, mail service type, label image type. etc. 
The mail service type specifies, for example, eitiier Priority Mail® or Standard 
B-mail. The label image type specifies tiie fomiat of tiie graphic image of the 
delivery confirmation barcode label. The label option indicates tiie type of 
infomiation that is to be included in the label. E-commerce sen/er 120 
generates an XML request for the delivery confimiation barcode label based 
on the itifonmation supplied by the end-user. 



For example, tiie XML request for a delivery confinnation barcode 
label includes the following tags: ■ 



Input 


XML Tag 


Values Allowed 


Type of 
Request 


<DeliveryConfirmationV2.0Request. . . 


Input tag exactly as 
j)resented. 


User ID 


...USERID="userid"... 


Use user ID provided with 
registration. 


Password 


. ..PASSWORD="password"> 


Use password provided 
with registration. 


Label 
Option 


<Option> 


Either of two values 
allowed: 

"1" for Label Option #1 or 
"2" for Label Option #2. 
For Label Option #1, a 
graphic image is returned 
that will include a 
barcode, PIC number. 
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return name and address, 
and delivery name and 
address. 

For Label Ootion #2 a 
graphic image is returned 
that will include a barcode 
and PIC number without 
the return and delivery 
name and address. 


Printer 
Definition 


< 1 magerarameiers^ 


This taa is for future use. 
The tag is required, but 
there are no values to 
enter. 


Name of 
Sender 


<FromName> 


Maximum characters 
allowed: 32 


Company 
Name 


^ ■ - — ————— ^ 

<Fromrirm> 


TFiiQ tan rpniiired hiit 

the value is optional. 
Maximum characters 


From 
Address 
Line 1 


<FromAddress1> 


Use this tag for an 

dpcll U 1 ICl 11 vl OUIIC3 

number. This tag is 

rpniilrprl htjf thp value is 

optional. Maximum 
characters allowed: 32 


From 
Address 
Line 2 


<FromAddress2> 


Maximum characters 


From City 


<FromCity> 


Maximum characters 
allowed: 21 


From 
State 


<FromState> 


Maximum characters 
allowed: 2 


From ZjP 
Code® 


<FromZip5> 


In nut tan pyantiv as 
presented, not all caps. 
Maxinmim characters 
allowed: 5 


From ZIP 


<FromZip4> 


Input tag exactly as 
presented, not all caps. 
This tag is required but 
the value is optional. 
Maximum characters 
allowed: 4 


Name of 
Recipient 


<ToName> 


Maximum characters 
allowed: 38 


Company 
Name 


<ToFirm> 


This tag is required but 
the value is optional. 
Maximum characters 
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allowed: 38 


To 

Address 
Line 1 


<ToAddress1> 


Use this tag for an 
aoartment or suite 
number. This tag is 
required but the value is 
optional. Maximum 
characters allowed: 38 


To 

Address 
Line 2 


<ToAddress2> 


Maximum characters 
allowed: 38 


To City 


<ToClty> 


Ma)dmum characters 
allowed: 21 


To State 


<ToState> 


Maximum characters 
allowed: 2 


To ZIP 
Code® 


<ToZlp5> 


Inniit t^n eyactiv as 

presented, not all caps. 

Mavimiim nhrirflcters 

IVIClAli 1 Ivl 1 1 1 i/l ICil OwliWl O 

allowed: 5 


To ZIP 
Code®+4 


<ToZip4> 


Input tag exactly as 
presented, not all caps. 
This tag is required but 
the value is optional. 
Maximum characters 
allowed: 4 


Package 
Weight 


<WeightinOunces> 


Value must be numeric. 


Mail 

Service 
Type 


<ServiceType> 


Either of two values are 
allowed 

"Priorit/' for Priority Mail® 
or 

"Standards" for Parcel 
Post™, Bound Printed 
Matter, Special Standard, 
or Library Rate, 


Label 

Image 

Type 


<lmageType> 


Either of two values 

allowed: 

TIF" or "PDF" 



Thereafter, e-commerce server 1 20 sends the XML request to a Web 
Tools API server 130 through network 110. Web Tools API server 130 
receives the XML request and calls a delivery confirmation service API 
module 285 to generate the requested delivery confirmation barcode label 
and to associate a PIC with the delivery confirmation barcode. Delivery 
confirmation service API module 285 sends the PIC and other information 
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such as the zip codes and package weight, to a tracking server 140, where 
the PIC and other information is stored in a tracidng database 160. In 
addition, delivery confirmation service API module 285 generates an XML 
response based on the delivery confirmation barcode label and the PIC. 
For example, the XML response includes the following tags: 



Output 


XML Tag 


Type of Response 


<DellveryConfimfiationV2.0Response> 


Delivery Confirmation'^ ID Number 
(PIC#) 


<DeliveryConfimiationNumber> 


Delivery Confirmation™ Label 


<DeliveryConfimnationLabeI> 



response. Web Tools API server 130 sends the XML response to e- 
commerce sender 120 through network 110. E-commerce server 120 receives 
the XML response and extracts the delivery confinnation barcode label and 
the PIC. Alternatively, Web Tools API server 130 may directly send the 
delivery confinnation barcode label and the PIC to e-commerce server 120 
Instead of generating and sending an XML response. E-commerce server 
120 sends the delivery confinnation barcode label and the PIC to the end-user 
at client system 101 through network 110. Client system 101 may display the 
delivery confinnation barcode label and/or the PIC to the end-user. 

Figure 13 is a flowchart showing a method for providing a delivery 
confirmation label. As shown in Figure 13, an end-user accesses an e- . 
commerce server 120 through a client system 101 (stage 1300). The end- 
user makes a request to e-commerce sen/er 120 for a delivery confirmation 
barcode label, and supplies information about the package on which the . 
delivery confinnation barcode label will be placed (stage 1310). The 
infonnation supplied by the end-user may include information about the 
sender, receiver, package weight, mail service type, label image type, etc. E- 
commerce server 120 generates an XML request for the delivery confinnation 
barcode label based on the infonnation supplied by the end-user (stage 
1320). Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API server 1 30 through network 1 1 0 (stage 1 330). 
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Web Tools API server 130 receives the XML request and calls a 
delivery confirmation service API module 285 to process the request. 
Delivery confinnation service API module 285 generates the requested 
delivery confinnation barcode label and assodates a PIC with the delivery 
confinnation barcode (stage 1340). Delivery confinnation service API nradule 
285 sends the PIC and ottier infbnnation such as the zip codes and package 
weight, to a tracking server 140, where the PIC and other infbnnatfon is stored 
In a tracking database 160 (stage 1350). In addition, delivery confirmation 
service API module 285 generates an XML response based on the delivery 
confirmation barcode label and the PIC (stage 1360). Next. Web Tools API 
server 130 sends the XML response to e-commerce server 120 through 
network 1 1 0 (stage 1 370). 

E-commerce server 1 20 receives the XML response and extracts the 
delivery confinnation barcode label and the PIC (stage 1380). E-commerce 
server 120 sends delivery confinnation barcode label and the PIC to the end- 
user at client system 101 through network 110 (stage 990). Client system 101 
may display the delivery confinnation barcode label and/or the PIC to the end- 
user. Alternatively, Web Tools API server 130 sends the delivery confinnation 
barcode label and the PIC instead of the XML response to e-commerce server 
120 through network 110 (stage 1370). Thereafter, e-commerce server 120 
sends the delivery confinnation barcode label and the PIC to the end-user at 
client system 101 through network 110 (stage 1380). 

Figure 14 is a block diagram showing data exchange occurring vnthin a 
system for a courtesy reply label API. The courtesy reply label API has been 
specifically designed for e-commerce entities that elect to have their 
customers pay the postage on a retum item, but still wish to provide a 
convenient retum label. This API facilitates returns by allowing e-commerce 
entities to request and receive a courtesy reply label for merchandise retum, 
which the e-commerce entity can provide to its customers or end-users 
through any known distribution medium, such as email, regular mail, fax, etc. 

As shown in Figure 14, an end-user accesses an e-commerce server 
120 over a network 110 through a client system 101 and makes a request to 
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return a purchased item to a retailer. E-commerce server 120 may provide to 
the end-user, based on infomiation supplied by the end-user, a list of items 
that were purchased. The.end-user may select from the list one or more 
items to retum. For purposes of this example, the end-user selects a single 
item. Thereafter; e-commerce server 120 detemiines whether the end-user 
has pemiission to retum the selected item, and If so, whether the item 
requires insurance for shipping. If the end-user has penmission to retum the 
selected item to the retailer, e-commerce server 120 generates an XML 
request based on the infomiation supplied by the end-user and the selected 
item. 

The request includes, for example, the name and address of the 
customer who purchased the item, name and address of the retailer who sold 
the item, sers^ice type, pemiit information, PDU information, label image type, 
insurance value, package weight, and RMA. 

For example, the XML request a courtesy reply label includes the 



following tags: 



Input 


XMLTaq 


Values Allowed 


Type of 
Request 


<CourtesyLabelRequest. . . 


Input tag exactly as presented. 


User ID 


...USERID="userid"... 


Use user ID provided with 
registration. 


Password 


. . .PASSWORD=''password"> 


. Use password provided with 
registration. 


Customer's 
Name 


<FromName> 


Maximum characters allowed: 
32 


Customer's 
Address 


<FromAddress1> 


Maximum characters allowed: 
32 


Customer's 
Address 


<FromAddress2> 


Maximum characters allowed: 

32 


Customer's 
City 


<FromCity> 


Maximum characters allowed: 
21 


Customer's 
State 


<FromState> 


Maximum characters allowed: 2 


Customer's 
ZIP Code® 


<FromZip5> 


Input tag exactly as presented, 
not all caps. Maximum 
characters allowed: 5 


Customer's 
ZIP Code® 


<FromZip4> 


Input tag exactly as presented, 
not all caps. Maximum 
characters allowed: 5 
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Retailer's 
Name 


<ToName> 


Maximum characters allowed: 
32 


Retailer's 
Address 


<ToAddress1> 


Maximum characters allowed: 
32 


Retailer's 
Address 


<ToAddress2> 


Maximum characters allowed: 
32 


Retailer's 
City 


<ToCity> 


Maximum characters allowed: 
21 


Retailer's 
State 


<ToState> 


Maximum characters allowed: 2 


Retailer's 
ZIP Code® 


<ToZip5> 


Input tag exactly as presented, 
not all caps. Maximum 
characters allowed: 5 


Retailer's 
ZIP Code® 


<ToZip4> . 


Input tag exactly as presented, 
not all caps. Maximum 
cnaraciers aiiowea. o 


Retailer 
Data 


<Comment> 


Value entry is optional. No 
restriction on number or type of 
characters. Any shipping or 
inventory information can be 
used with this tag. Any 
information entered with this tag 
will appear on the lat>el. 


Label Image 
Type 


<lmageType> 


Either of two values allowed: 
TIF" or "PDF" 



Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API server 130 through network 110 (stage 330). Web Tools API 
server 130 receives the XML request and calls a courtesy reply label API 



module 285 to generate the courtesy reply label based on the-XML request. 
The courtesy reply label may, for example, be In PDF or TIF fomiat, which Is 
determined by the value supplied in the Label Image Type tag. Next, courtesy 
reply label API module 285 generates an XML response, which includes the 
courtesy reply label. For example, the XML response includes the following 



tags: 



Output 


XML Taa 


Tvpe of Response 


<CourtesvLabelResDonse> 


Imaqe of Courtesy Label 


<CourtesyLabel> 



After courtesy reply label API module 285 generates the XML 



response. Web Tools API server 1 30 sends the XML response to e- 
commerce server 120 through network 110. E-commerce server 120 receives 
the XML response and extracts the courtesy reply label. E-commerce server 



wo 02/17045 



PCTAJSO 1/26656 



35 

120 may send the courtesy reply label to client system 101 through network 
110. Client system 1.01 may display the courtesy reply label to the end-user. 
The end-user may then print the courtesy reply label and attach It to the 
packaged Item. Altematively, e-commerce server 120 may fax the 
merchandise retum label to the end-user, email the merchandise return label 
to the end-user, or mail it to the end-user. 

Figure 15 is a flowchart showing a method for providing a courtesy 
reply label. As shown in Figure 15, an end-user accesses an e-commerce 
server 120 through a client system 101 , and makes a request to retum 
merchandise to a retailer (stage 1 500). E-commerce server 120 may display 
to the end-user, based on infonmation supplied by the end-user, a list of items 
of merchandise that were purchased from the retailer (stage 1 505). The end- 
user selects from the list an item of merchandise to retum (stage 1510). 
Thereafter, e-commerce server 120 determines whether the end-user has 
permission to retum the selected merchandise by requesting approval from 
the retailer (stage 1515). If the end-user does not have permission to return 
the merchandise to the retailer ("No"), e-commerce server 120 sends a 
message to the end-user informing her that her request is denied and the 
transaction stops (stage 1520). OthenArise (Tes"), the end-user has 
permission to retum the merchandise to the retailer. E-commerce server 120 
generates an XML request based on the information supplied by the end-user 
and the selected merchandise (stage 1 525). 

Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API sen/er 1 30 through network 1 1 0 (stage 1 530). Web Tools API 
server 1 30 receives the XML request and calls a courtesy reply label API 
module 285 to process the request (stage 1535). Next, courtesy reply label 
API module 285 generates an XML response, which includes the courtesy 
reply label (stage 1540). Web Tools API server 130 sends the XML response 
to e-commerce server 120 through networt^ 110 (stage 1545). E-commerce 
server 120 receives the XML response and extracts the courtesy reply label 
(stage 1550). E-commerce server 120 sends the courtesy reply label to the 
end-user at client system 101 through network 110 (stage 1555). Client 
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system 101 displays the courtesy reply label to the end-user. The end-user 
may then print the courtesy reply label, attach it to the packaged Item, and 
apply postage to the package. Alternatively, e-commerce server 120 may fax 
the courtesy reply label to the end-user, email the courtesy reply label to the 
end-user, or mail it to the end-user. 

Figure 16 is a block diagram showing data exchange occuning within a 
system for an address information service API. The address infomnation 
service API's provide access to standard address fomiats ("address 
infomiation") and may include, but is not limited to, a city/state lookup API, 
ZIP code lookup API, and address standardization API. The ZIP code lookup 
API receives as Input a given city and state code and retums a corresponding 
ZIP code. The dty/state lookup API receives as input a given ZIP code and 
retums the cify and state con-esponding to the ZIP code. The address 
standardization API receives as Input an address and corrects enors in the 
address, such as enors in street or city names and/or enors in the ZIP code, if 
any. 

E-commerce entities needing to validate address infonmation provided 
by an e-shopper or end-user may use one or more of the address infonnation 
service API's to check the address infonnation provided by tiie e-shopper or 
end-user. Alternatively, an end-user may request the e-commerce entity to 
provide a Zip code for a given city and state. The e-commerce entity may 
send a request to the ZIP code lookup API. which retums the requested ZIP 
code to the e-commerce entity. 

As shown in Figure 16, an end-user accesses an e-commerce sender 
120 over a network 110 through a client system 101 and makes a request for 
address infomiatlon, such as the city and state information for a ZIP code 
specified by the end-user. E-commerce server 120 generates an XML 
request for the address information based on the infomiation supplied by the 
end-user. 

For example, the XML request for city/state lookup includes the 
following tags: 
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input 


XML Tag 


Type of Request 


<CityStateLookupRequest. . . 


User ID 


...USERID="userid"... 


Password 


. . .PASSWORD="password"> 


ZIP Code Lookup Number^ 


<ZiDCode ID='#'> 


ZIP Code of City or State 


<Zip5> 


For example, the XML request for ZIP code lookup includes the 
following tags: 


Input 


XML Tag 


Type of Request 


<ZipCodeLookupRequest. . . 


User ID 


...USERID="userid"... 


Password 


. . PASSWORD="password"> 


Address Lookup Number^ 


<Address ID='#'> 


Name of Firnn^ 


<FinnName> 


Address Line I'* 


<Address1> 


Address Line 2^ 


<Address2> 


City 


<City> 


State 


<State> 


For example, the XML request for address standardization lookup 
includes the following tags: 


Input 


XML Tag 


Type of Request 


<AddressValidateRequest. . . 


User ID 


...USERID="userid"... 


Password 


. . PASSWORD="password''> 


Address Verification Number^ 


<Address ID=T> 


Name of Flrm^ 


<FirmName> 


Address Line 1 


<Address1> 


Address Line 2 


<Address2> - 


City 


<Citv> 


State 


<State> 


ZIP Code® 


<Zip5> 


ZIP Code® + 4 


<Zip4> 



Thereafter, e-commerce server 120 sends the XML request to a Web 
Tools API server 1 30 through network 1 1 0. Web Tools API server 1 30 
receives the XML request and calls an address information service API 
module 285 to process the request. Address information service API module 
285 searches a shipping information database 150 for the requested address 
infomnation based on the XML request Shipping infonnation database 150 
may include, for example, an address database. Next, address information 
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seivice API module 285 generates an XML response based on retrieved 
address information. . 

For example, the XML response for city/state lookup includes the 



following tags: 



output 


XML Tag 


Type of Response 


<CityStateLookupResponse... ■ 


ZIP Code Lookup Number 


<ZiDCode ID='#'> 


ZIP Code of City or Slate 


<Zip5> 


City for Requested ZIP Code® 


<City> 


State for requested ZIP Code® 


<State> 


For example, the XML response for ZIP code lookup includes the 
following tags: 


Output 


XML Tag 


Type of Response 


<ZipCodeLookuj3Response> 


Address ID Number 


<Address ID='#'> 


Name of Firm* 


<FlnnName> 


Address Line 1* 


<Address1> 


Address Line 2* 


<Address2> 


City 


<Citv> 


State 


<State> 


ZIP Code 


<ZiD5> 


ZIP Code + 4 


<Zip4> 


For example, the XML response for address standardization lookup 
includes the following tags: 


Output 


XML Tan 


Type of Response 


<AddressValidateResponse> 


Address Verification Number 


<Address ID=«*> 


Name of Finm* 


<FinnName> 


Address Line 1 


<Address1> 


Address Line 2 


<Address2> 


City 


<City> 


State 


<State> 


ZIP Code® 


<Zip5> 


ZIP Code® + 4 


<Zip4> 



After address Infomriation service API module 285 generates the XML 



response. Web Tools API server 130 sends the XML response to the e- 
commerce server 120 through network 110. E-commerce server receives the 
XML response and extracts the address infomiation. E-commerce server 
120 sends the address information to the end-user at client system 101 
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through network 110. Client system 101 may display the address infomnaf on 
to the end-user. Alternatively, Web Tools API server 130 sends the address 
Infomiation instead of the XML response to e-commerce server 120 through 
network 110. Thereafter, e-commerce server 120 sends the address 
Information to the end-user at client system 101 through network 110. 

Figure 17 is a flowchart showing a method for providing address 
infonnation. As shown In Figure 17, an end-user accesses an e-commerce 
server 120 through a client system 101 (stage 1700). The end-user makes a 
request to e-commerce server 120 for address infomnation. such as the city 
and state Infonnation for a ZIP code specified by the end-user (stage 1710). 
E-commerce server 120 generates an XML request for the address 
Information based on the Infomnatlon supplied by the end-user (stage 1720). 
Thereafter, e-commerce server 120 sends the XML request to Web Tools API 
server 1 30 through network 1 1 0 (stage 1 730). 

Web Tools API server 1 30 receives the XML request and calls an 
address information service API module 285 to process the request (stage 
1740). Address infonnation ser>flce API module 285 searches a shipping 
Infonnation database 150 for the requested address Infomiation based on the 
XML request and retrieves the requested address Infbrmation. Shipping 
information database 150 niay Include, for example, an address database. 
Next, address infonnation service API module 285 generates an XML 
response based on the retrieved address infonnation (stage 1750). Web 
Tools API server sends the XML response to e-commerce server 1 20 through 
network 110 (stage 1760). E-commerce server receives the XML response 
and extracts the address infonnation. E-commerce server 120 sends the 
address information to the end-user at client system 101 through network 110 
(stage 1770). Client system 101 may display the address infonnation to the 
end-user. Alternatively, Web Tools API server 130 sends the address 
information instead of the XML response to e-commerce server 120 through 
network 1 10 (stage 1 160). Thereafter, e-commerce server 120 sends the 
address infonnation to the end-user at client system 101 through network 110 
(stage 1170). 
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In another example, an end-user accesses an e-commerce server 120 
through a client system 101 . The end-user provides a delivery address to e- 
commerce server 120 for the shipment of a purchased item. E-commerce 
server 120 generates an XK/IL request for the validation of the address 
information. Thereafter, e-commerce server 120 sends the XML request to a 
Web Tools API sender 1 30 through network 110, 

Web Tools API server 1 30 receives the XML request and calls an 
address infomiation service API module 285 to process the request. Address 
infomiatlon service API module 285 searches a shipping infomiation database 
150 for address infomiation based on the XML request, and using infomiatlon 
from the address, conrects errors or omissions to the address infomiation in 
the XML request. Shipping information database 150 may include, for 
example, an address database. Next, address infonnation service API 
module 285 generates an XML response based on the address information 
and confections to the address information. 

Web Tools API server sends the XML response to the e-commerce 
server 120 through network 1 10. E-commerce server 120 receives the XML 
response and extracts the address information. E-commerce server 120 
generates an XML request for a delivery confirmation label based on the 
address infomiation. Thereafter, e-commerce server 120 sends the XML 
requesttoa Web Tools API server 130 over network 110. - 

Web Tools API server 130 receives the XML request and calls a 
delivery confinnation service API module 285 to generate the requested 
delivery confinnation barcode label and to associate a PiC with the delivery 
confinmation barcode. Delivery confirmation service API module 285 sends 
the PIC and other infomiation such as the zip codes and package weight, to a 
tracking server 140, where the PIC and other infomiation is stored in a 
tracking database 160. In addition, delivery confirmation service API module 
285 generates an XML response based on the delivery confirmation barcode 
label and the PIC. Web Tools API server 130 sends the XML response to e- 
commerce server 120 through network 110. E-commerce server 120 may 
send the delivery label to the end-user using any known delivery method. 
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Other embodiments of the invention will be apparent to those skilled in 
the art from consideration of the specification and practice of the invention 
disclosed herein. It is intended that the specification and examples be 
considered as exemplary only, with a true scope and spirit of the invention 
being indicated by the following claims. 
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WHAT IS CLAIMED IS: 

1 . A method for providing shipping services infonnation over a network, 
comprising: 

providing instructions to a firist server from a second server which 
permits the first server to access the shipping services information residing on 
the second server over the networic; 

receiving a request from a dient for the shipping services Infonnation at 
the second server through the first server, and 

providing, the requested shipping services information from the second 
server to the client through the first server. 

2. The method of claim 1 wherein the shipping services Information is 
provided in a format to produce a label. 

3. The method of daim 2 wherein the label includes forwarding 
information thereon. 

4. The method of daim 3 wherein the fonA^arding Infonnation indudes at 
least one of addressing information, barcode infonnation, return authorization 
number and an indication of pre-paid postage. 

5. The method of claim 1 wherein the shipping service information 
irjcludes. shipping rates information. 

6. The method of claim 1 wherein the shipping service infonnation 
includes at least one of tracking infonmation and confirmation infomnation. 

7. The method of claim 1 wherein the shipping service information 
includes at least one of service standards and commitment standards 
infonnation for a shipment option. 
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8. The method of claim 1 wherein the shipping service Infomiatlon 
includes standard address fbrniats infonmation. 

9. The method of claim 1 wherein the instnjctions may operate on any of 
a plurality of types of operating systems which reside on the first server. 

10. A method for providing shipping services information over a nefworl^, 
comprising: 

providing instructions to a first sev/er over the networic from a second 
server which pemiits the first server to access the shipping services 
information residing on the second server, 

receiving a request from the first server over the network to the second 
server for the shipping services information; 

retrieving the requested shipping services Infonnation; 

and 

sending the retrieved shipping services infomiation from the second 
server to the first server over the networic, 

1 1 . The method of claim 10 wherein the request is generated by the first 
server based on one or more of the instructions provided by the second 
server. 

12. The method of claim 10 wherein the step of retrieving comprises 
retrieving the requested shipping services infdnnation from one or more 
databases. 

13. The method of claim 10 wherein the shipping services infomiation is 
provided in a fonnat to produce a courtesy reply label. 
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14. The method of claim 1 0 wherein the shipping services infomiation is 
provided In a fonmat to produce a merchandise return label. 

1 5. The method of daim 1 0 wherein the shipping services information is 
provided in a format to produce a delivery confinnation tiarcode label. 

16. A system for providing shipping services infonnation over a network, 
comprising: 

means for providing InstmcHons to a first server from a second server 
which permits the first server to access the shipping services information 
residing on the second sen/er over a network; 

means for receiving a request ftom a client for the shipping sen/ices 
infomiation at the second sen/er through the first server, and 

means for providing the requested shipping services infonnation frohri 
the second server to the client through the first server. 

17. A system for providing shipping services infonnation over a networi<, 
comprising: 

means for providing instructions to a first server over a network from a 
second server which pennits the first sender to access the shipping services 
infomiation residing on the second server; 

means for receiving a request from the first server over the networl< to 
the second server for the shipping sen/ices infiormation; 

means for retrieving the requested shipping services infonnation; 

and 

means for sending the retrieved shipping services information from the 
second server to the first server over the networl<. 
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18. A system for providing shipping services information over a network, 
comprising: 

a module for providing instmctions to a first server from a second 
server which pemiits the first server to access the shipping services 
information residing on the second server over a networic; 

a module for receiving a request from a dient for the shipping services 
infomiation at the second server through the first server, and 

a module for providing the requested shipping services infomiation 
from the second server to the client through the first server. 

19. A system for providing shipping services information over a network, 
comprising: 

a module for providing instructions to a first server over a networi< from 
a second server which pemiits the first server to access the shipping services 
infonnation residing on the second server, 

a module for receiving a request from the first server over the networi< 
to the second server for the shipping services' information; 

a module for retrieving the requested shipping services infonnation; 

and 

a module for sending the retrieved shipping services infonnation from 
the second server to the first sen/er over the networic. 
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